home *** CD-ROM | disk | FTP | other *** search
/ BCI NET 2 / BCI NET 2.iso / archives / programming / languages / turbo_part1.lha / modula / docs / CACHE.DOC < prev    next >
Encoding:
Text File  |  1995-01-24  |  4.7 KB  |  100 lines
  1.                 File Caching
  2.                 ============
  3.  
  4.     Turbo V1.2 introduced symbol & object file caching.
  5.     The desire is of course to speed up compilation & linking.
  6.     Its always been possible to make m2b, m2c, m2l, dcc, dlink resident,
  7.     (S/RESALL script will make them resident for you) which speeds things up
  8.     too. However caching and residence will eat memory.
  9.  
  10. Symbol File Cache
  11. -----------------
  12.  
  13.     M2C generates a persistent symbol file cache data structure, this
  14.     cache is anchored on the '!m2cache' message port (maintained by Exec).
  15.     This port is for internal use only, dont try to send it any messages.
  16.  
  17.     Symbol file caching is by default enabled, 'setenv M2SYMCACHE=OFF' if you
  18.     dont have the memory and so want to disable it. If no M2SYMCACHE env-var
  19.     exists, symbol file caching is assumed ON.
  20.  
  21.     Symbol files are only cached when they are loaded not when they are written.
  22.     The cache contains expanded images of the symbol files on disk.
  23.     The loaded image is typically 4 times larger than the one on disk.
  24.  
  25.     The cache can contain multiple versions of the same named symbol file.
  26.     This means you can change directory and start compiling a different program
  27.     with the same named modules with out having to flush the cache.
  28.     The compiler decides which cached version to use by examining the disk based
  29.     symbol files internal timestamp (this requires a disk access to read the
  30.     first 20 bytes).
  31.     M2C insists that there always be a disk based symbol file.
  32.     If no cached symbol file matches the one on disk (even if any have the same
  33.     name), then the disked symbol file will be loaded into the cache.
  34.  
  35.     The compiler will automatically handle cache updating:
  36.     When a symbol file is generated by the compiler (when you compile a .def),
  37.     then the compiler will automatically remove any copy of the overwritten
  38.     symbol file from the cache. It will then recursively remove any cached
  39.     symbol file that used (imported) the removed one.
  40.     However if you manually c:delete a symbol file from disk, then any
  41.     cached copy will remain in the cache until it is flushed (by M2F).
  42.  
  43.     Use bin/M2S to see which files have been cached.
  44.     Use bin/M2F to flush the symbol file cache.
  45.  
  46.     Only one process (m2c,m2s or m2f) can be accessing the cache at any time,
  47.     If a second m2c is started while the first is still running, then the
  48.     second m2c degenerates to reading off disk.
  49.     This should not be too much of a problem: When did you last mulitask M2C
  50.     with itself?
  51.  
  52.     The speed up in compilation (as a result of symbol file caching) is most
  53.     noticeable on slower Amigas.
  54.  
  55. Object File Cache
  56. -----------------
  57.  
  58.     Unlike symbol files, object files are not cached by default, the
  59.     S/TURBOLINK script will enable the object file cache.
  60.  
  61.     Object file caching is not as good as the symbol file caching mechanism
  62.     because i dont have access to the internal parts of the linker.
  63.     To improve things, i could implement my own linker, but this is low on my
  64.     list of priorities.
  65.     The object file cache uses the RAM DISK to store copies of used object
  66.     files, so as to avoid loading from disk. This is not as efficient as
  67.     making the object file 'resident', since during linking there will
  68.     effectively be two copies in ram.
  69.  
  70.     To really speed linking you must make M2L, DCC, DLINK resident and copy and
  71.     reassign dlib:#? to ram:, the S/TURBOLINK script will do all this for you.
  72.     By doing all the above, disk activity during linking is greatly reduced and
  73.     so linking should be faster. This gives the most speed up on high end
  74.     Amigas (030/25+), where disk access is probably the main performance bottle
  75.     neck (during linking at least). Slower Amigas will also benefit, but its
  76.     only worth doing on slower machines if you have the spare memory.
  77.  
  78.     Dont start the TURBOLINK script unless your system has 500Kbs of spare ram.
  79.  
  80.     The environment variable M2OBJCACHE must point a ramdisk directory.
  81.     M2L will read the M2OBJCACHE env-var and cache object files into the
  82.     directory it point to.
  83.     The TURBOLINK script will create and assign M2OBJCACHE for you.
  84.  
  85.     The S/OFLUSH script will flush the object file cache.
  86.     The S/OSHOW script will list the cache directory.
  87.  
  88.     If you intend to use the above scripts make sure 'modula:s' is in your path,
  89.     s/startup adds it, also make sure the 's' bit is set on all the files
  90.     in this directory (LHA clears them unless you extract the archive with -a):
  91.  
  92.     >protect modula:s/#? s add
  93.  
  94.     Doing this avoids the need to prefix the 'execute' command when starting
  95.     the scripts.
  96.  
  97.     Any object files created with M2C V1.1 will not be cached.
  98.  
  99.     It took me 20 times longer to implement the symbol file cache.
  100.